Many businesses and other enterprises nowadays store vast amounts of data in databases, often using commercially available database platforms in conjunction with software applications capable of accessing and processing the data to extract meaningful information therefrom in support of various business processes. For example, software applications for enterprise resource planning, customer relationship management, supplier relationship management, supply chain management, and product lifecycle management are widely used across many industries. In many deployment scenarios, such software applications are centrally executed on an application server (integrated or in communication with the database platform) that may be accessed by users, for example, via web portals. Many different instances of the same application may run simultaneously, each within a respective user session.
Existing software applications may be modified from time to time by a developer to adjust them to changing business needs, correct errors found during use, or improve user experience, among other reasons. With widely used applications, it is likely that, at the time the developer activates a new version of an application, the previous version of the same application is currently in use by one or more other users. In this situation, it is desirable that these users can complete execution of the old application version (or at least continue execution of the old application version until a stable state is reached, such as when data is saved), while other users freshly starting the application obtain immediate access to the new version. Similarly, in large development projects, multiple developers may implement changes to different (or even the same) parts of an application in parallel, and one developer may wish to deploy her modification without affecting the execution of previous versions of the applications that are in use by the other developers. Accordingly, in both scenarios, multiple different versions of the same application may be running in parallel over a certain time period (e.g., minutes, hours, or even days). It is important, during this period of version overlap, to avoid inconsistencies that may arise, for instance, if an established session switches inadvertently, and/or unbeknownst to the user, from the older version to the newer version. The activation of a new application version in a manner that is not, or only minimally, disruptive to the current execution of a previous version (hereinafter referred to as “hot deployment” of the new version) can generally be accomplished with a suitable “multi-version-capable” infrastructure that keeps track of the versions of executed applications.
With a growing need for real-time data access and increasing amounts of data, a trend has emerged to move data-processing functionality closer towards the database to reduce the frequency with which the database is accessed by external programs. This “code push-down” can be accomplished through the use of database procedures that are executed within the database itself. Database procedures, however, are limited in the types of operations they can perform. Furthermore, while databases are generally multi-version capable with respect to the data they store (allowing one user to update data in the database without affecting another user's access to the previous version of that data), this capability does not extend to database procedures. Accordingly, if changes to an existing software application involve modifications to one or more database procedures, inconsistencies can arise whenever the modification is deployed while an application utilizing the old database procedure version is still in use.